想要搞明白Checkmarx容器镜像扫描怎么开启，还有扫描失败了该怎么排查，不能只想着把代码仓库交给工具扫一遍就行，更重要的是先搞清楚扫描的对象到底是什么，是Dockerfile里的基础镜像，还是已经构建好的成品容器镜像。Checkmarx的Container Security模块可以扫描项目里的Dockerfile，找出里面用到的容器镜像，还有镜像存在的风险；如果用CLI命令运行，还能指定公共或者私有仓库里的具体镜像来扫描。

在Checkmarx里，漏洞分派怎么去设，还有分到开发手里以后怎么跟下去，好多团队把安全扫描接进来以后，都会撞上这个问题。扫描结果出来了，要光靠安全的人在平台里翻报告，开发那头根本闹不清该修哪条、什么时候修、修完又怎么认，那漏洞管理这档子事，就死死地卡在“发现”这一步上了。Checkmarx One能看扫描结果、管漏洞，也能走API、Webhook这些门道去跟外头的流程接上；SAST结果查看器，也就是在项目代码里认漏洞、管漏洞用的。

在Checkmarx里面，预设规则集要怎么选，还有这套规则集跟项目语言又要怎么匹配，不能光想着“规则越多就一定越安全”。预设规则集这东西，说到底，就是一整套查询规则，它的作用是在跑SAST的时候，决定到底要重点去查哪些漏洞类型、哪些风险级别，还有哪些跟语言挂钩的规则。Checkmarx One的文档里面也讲过，Presets就是一组可以让你去选的查询规则，SAST扫描必须选定一个预设规则集，要是你没去挑，它就会自己用上那套默认的。

关于Checkmarx误报标记要怎么处理，还有标记误报之后重新扫描为什么还会显示，首先要分清楚两种情况，一种只是修改结果的展示状态，另一种是真正把这个风险从之后的扫描结果里排除掉。在Checkmarx One当中，SAST的扫描结果可以做分类处理，用户可以修改结果的状态或者严重等级；如果判断某个漏洞没法被利用，官方文档里对应的做法是标记为Not Exploitable，这样后续同一个项目的扫描里，通常就不会再继续显示这个漏洞了。

在Checkmarx里面，数据流路径到底要怎么去看，还有数据流路径跟断点为什么老是对不上，很多情况下，这并不单单是工具本身的问题。安全扫描那一头，它看到的是代码里头，那些有可能存在的数据传播的路径，而本地调试这一边，它看到的，是某一次运行的时候，到底有没有真正走到那个地方。一个更偏向于静态分析，一个更偏向于实际执行，两边的结果不完全吻合，这也是很正常的事情。排查的时候，不能只把眼睛盯在漏洞的名字上面，也不能就只看最后那一行sink，还是要把输入的来源、中间是怎么传递的、最后那个危险的调用，这好几段东西连在一起去看。

关于Checkmarx增量扫描的开启方法，还有出现漏报问题时的排查思路，不能简单把增量扫描理解成扫描速度变快；增量扫描的核心作用是缩小扫描的范围，一般只扫描和上一次基准扫描相比发生改动的代码，还有和改动代码存在关联的部分内容。根据Checkmarx官方文档的说明，SAST增量扫描会对上次扫描之后出现的代码改动进行检测，以此缩短扫描的时长，降低资源的消耗；同时文档也提到，全量扫描的结果会更完整，但是花费的时间也会更长。

团队里预设被反复改动，表面看是有人点错了几下，实质是预设被当成了个人偏好而不是受控配置，结果就是同一个仓库今天扫出一批问题，明天换了预设又变了口径，研发与安全两边都很难对齐。要把这件事管住，思路分两条线：一条线把预设的创建、更新、删除权限收紧，另一条线把预设本身做成可追溯、可回滚的配置资产。

分支扫描看起来覆盖不全，常见有两类情况：一类是分支确实没有把该扫的分支触发起来，或文件被过滤规则排掉了；另一类是你在拉取请求也称为Pull Request的视图里只看到New Issues，以为老问题没扫到。先把现象归类，再去改触发分支与文件过滤，会比反复重跑扫描更快。

很多团队遇到的现象是扫描一跑就把节点CPU打满，内存一路涨，队列越堆越多，最后要么扫描超时，要么节点被挤到不可用。处理这类问题不要只盯着加硬件，更关键是把并发、扫描范围、扫描类型三件事先压住，再用平台自带的引擎限制与分支规则把资源曲线拉平。

Checkmarx把结果标成误报后又出现，最常见的不是你没点对按钮，而是复扫时这条结果在系统里被识别成了另一条实例，或者抑制只对当前项目生效，你却换了分支、换了项目、换了扫描配置。要把问题一次性压住，你需要先确认抑制到底有没有保存成功，再把复扫复现条件统一，最后再决定要不要把抑制范围从项目扩展到应用层。